[azure-ai-ml] Populate DeploymentTemplate.creation_context from systemData#47913
Merged
swarupecenits merged 3 commits intoJul 8, 2026
Merged
Conversation
…mData DeploymentTemplate._from_rest_object never deserialized the service's systemData, so creation_context was always None, unlike Model and Environment which populate it. Read system_data from the REST object and pass creation_context to the entity, and add regression tests. Fixes bug #5402673.
swarupecenits
requested review from
JustinFirsching,
NonStatic2014,
achauhan-scc,
arunsu,
jayesh-tanna,
kingernupur,
nick863,
novaturient95,
rtanase,
sharma-riti and
vivram
as code owners
Member
Author
|
@microsoft-github-policy-service agree company="Microsoft" |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a deserialization gap in the azure-ai-ml package where DeploymentTemplate.creation_context was always None after retrieval via get() or list(), even though the service returns created/modified timestamps and identities in systemData. The fix makes DeploymentTemplate consistent with the Model and Environment entities, which already populate creation_context.
I verified that:
SystemDatais imported from the correct module (azure.ai.ml.entities._system_data), andSystemData._from_rest_objectreads fields viagetattr, so it works with the real REST model.- The REST
DeploymentTemplatemodel exposessystem_dataas a top-levelrest_field(name="systemData"), so reading it from the top-level object (notproperties) is correct, and thesystem_data/systemDatadual-key lookup covers both object and raw-dict payloads. DeploymentTemplate.__init__acceptscreation_contextvia**kwargsand forwards it to the parentResource, so the new argument is valid.- The pattern (
SystemData._from_rest_object(...) if ... else None) matches ~20 existing call sites across the package. - The two new tests use the same
Mock(spec=[])approach already used by neighboring tests, and their assertions are logically sound (including the absent-systemData→Nonecase).
Changes:
- In
_from_rest_object, readsystemDatafrom the REST object and populatecreation_contextviaSystemData._from_rest_object, covering bothget()andlist(). - Added two regression unit tests (populated and absent
systemDatacases). - Added a CHANGELOG entry under the unreleased
1.35.0"Bugs Fixed" section.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
azure/ai/ml/entities/_deployment/deployment_template.py |
Imports SystemData and deserializes system_data/systemData into creation_context in _from_rest_object. |
tests/deployment_template/unittests/test_deployment_template.py |
Adds tests asserting creation_context is populated from systemData and stays None when absent. |
CHANGELOG.md |
Documents the bug fix under 1.35.0 (unreleased) → "Bugs Fixed". |
…eploymentTemplate.creation_context The deployment-template API returns creation metadata as flattened createdTime / modifiedTime / createdBy fields rather than a nested systemData block, so _from_rest_object was still producing creation_context=None against the live service. Read those flattened fields (with a systemData fallback), parse the timestamps to datetime, and update the unit tests to use the real REST model. Verified against the live azure-huggingface registry. Fixes bug #5402673.
…s (list shape) Address PR review: creation_context was only read from the top-level object, so it worked for get() but stayed None for list(), where createdTime / modifiedTime / createdBy are nested under properties. Read properties-first with an obj fallback, and parse the stringified createdBy that list() returns to surface the userName. Verified against the live azure-huggingface registry for both get() and list(). Adds a nested-in-properties regression test.
kingernupur
approved these changes
Jul 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Notes
DeploymentTemplate.creation_contextwas alwaysNonewhen a template was retrieved viaget()orlist().DeploymentTemplate._from_rest_objectdid not deserialize the service'ssystemData, so the created/modified timestamps and identities were never populated — inconsistent withModelandEnvironment, which already populatecreation_context.system_data(object) /systemData(raw dict) from the REST object and passcreation_context=SystemData._from_rest_object(...)into the entity. This covers bothget()andlist()and mirrors the existingModel/Environmentpattern.Testing
test_deployment_template_from_rest_object_populates_creation_context— asserts the timestamps/identities are populated fromsystemData.test_deployment_template_from_rest_object_creation_context_none_when_absent— assertscreation_contextstaysNonewhensystemDatais absent.test_deployment_template.py: 23 passed.blackformatting clean.Description
Fixes internal bug #5402673.
DeploymentTemplate.creation_contextnow surfaces the created/modified metadata (created_at,created_by,last_modified_at,last_modified_by) that the service returns insystemData, making it consistent withModelandEnvironment. Previously it was alwaysNoneeven though the data was present in the REST response (a deserialization gap in the SDK entity, not missing service data).All SDK Contribution checklist:
General Guidelines and Best Practices
Testing Guidelines
Root cause
DeploymentTemplate._from_rest_objectnever deserialized the REST object'ssystem_data,so
creation_contextfell back to its default ofNone. The data is present in theresponse (surfaced via the REST
properties/systemData), so this was a deserializationgap in the SDK entity, not missing service data.
Repro Bug (repro_bug.py)
Fix
SystemDataindeployment_template.py._from_rest_object, readsystem_data(object) /systemData(raw dict) from theREST object and pass
creation_context=SystemData._from_rest_object(...)into the entity.This covers both
get()andlist().This mirrors how
ModelandEnvironmentalready populatecreation_context.Tests
test_deployment_template_from_rest_object_populates_creation_context(asserts thetimestamps/identities are populated).
test_deployment_template_from_rest_object_creation_context_none_when_absent(asserts it stays
NonewhensystemDatais absent).test_deployment_template.py: 23 passed.blackformatting clean.Related